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(54) Title: SECURE INTERNET PAYING AGENT WITH MOBILE TELEPHONE VALIDATION 

(54) Titre : M ANDATAIRE DE PAIEMENT SECURISE INTERNET AVEC VALIDATION PAR TELEPHONE MOBILE 
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AA...BANK CARD NETWORK 
3/1.. AUTHORISATION REQUEST 
4/1.. AUTHORISATION REPLY 
6/1...PAYMENT INTERMEDIARY A 
BB...PAYMENT INTERMEDIARY B 
CC... SELLER SITE 

1/1... PAYMENT REQUEST TO INTERMEDIARY 
DO.. .CLIENT TERMINAL 
EE...CUENT NUMBER 

(57) Abstract: The invention concerns an Internet server acting as secure paying agent, that is relaying all payment requests to bank 
card payment systems requiring card number input. The client is registered once on the server by supplying among others his bank 
card number and by installing a standard X509 certificate on his terminal, protected by a security code known only to him. When 
purchasing from his initialised PC, the payment request is relayed to the agent server which authenticates the client through his X509 
certificate, causing the security code to be requested on the client terminal. The client using such a secure system, accepts not to 
challenge a purchase carried out by the agent A request made from an anonymous PC (that is non-initialised), is blocked until a 
secure validation procedure is carried out Three validating procedures are proposed: 1) validation from a WAP mobile telephone; 
2) validation from a normal mobile telephone; 3) validation for a WAP mobile telephone with WIM module. 
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(57) Abrege : Serveur Internet agissant comme mandataire de paiement securise, c'est a dire relayant des requetes de paiement vers 
des systemes de paiement par carte bancaire demandant la saisie du numero de carte. Le client s*enregistre une fois sur le serveur 
en foumissant entre autres son numero de carte bancaire et en installant un certificat X509 standard sur son terminal, protege par un 
code securite connu de lui seuJ. Lors d'un achat depuis son PC initialise, la requete de paiement est relayee vers le serveur mandataire 
qui authentifie le client a travers son certificat X509, provoquant la demande du code de s6curit6 sur le terminal client. Le client 
utilisant un tel systeme securise, accepte de ne pas contester d* achat passe par le mandataire. Une requete d' achat pas see depuis 
un PC anonyme (c'est a dire non initialise) au mandataire, est bloquee sur le mandataire jusqu'a ce q'une procedure de validation 
sdcurisee soit effectuee. Trois procetiures de validation sont proposees: 1 . validation depuis du telephone mobiel WAP 2. validation 
depuis un telephone mobile normal 3. validation depuis du telephone mobile WAP avec module WIM. 
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MAN DAT AIRE DE PAIEMENT SECURISE INTERNET AVEC VALIDATION PAR TELEPHONE MOBILE 

Problematique ciblee et Etat de Tart 

Une des problematiques du paiement sur Internet est de reduire les contestations de transactions passes en 
5 ligne, en mettant en place des solutions garantissant la s£curite et la non repudiation par le client. 

Par ailleurs, les solutions s6curis£es existantes sont essentiellement basees sur un acces par terminal PC. Le 
d£veloppement du marche des mobiles, cr6e de nouveaux bespins d'achat en ligne multi-terminaux et disposer d\ui 
systeme coherent unique permettant de payer des achats en boutique depuis son PC, depuis un PC anonyme, ou 
depuis son telephone mobile serait un avantage certain. 



35 



50 



Les solutions proposees aujourd'hui en termes de paiement en ligne depuis les PC avec navigateur utilisent 
Tun des moyens suivants : 



1 . introduction d'un terminal securis6 auxiliaire disposant d'un lecteur de carte bancaire (systfcme du type 
1 5 de celui propose par la societe CyberCOMM), 

2. utilisation de certiflcats electroniques, comme SET 

3. transmission du numero de carte en ligne sur une liaison chiffree (ex : en utilisant un protocole comme 
SSL exploitant de la cryptographic publique du type Diffie-Helmann) 

20 La premiere approche n6cessite la mise en place d'un terminal specifique (ecran, clavier, processeur) chez 

le client utilisant la carte bancaire a puce comme les terminaux d'achat classiques. Ce moyen est considere comme 
non repudiable. 

La deuxieme approche est basee sur des certificats non standards et n'est pas strictement non repudiable car 
base sur du logiciel installe sur des postes tres ouverts comme les PC des clients. 
25 La troisieme approche est la plus utilisSe aujourd'hui car ne n^cessitant aucune installation de la part du 

client, mais c'est elle qui declenche le plus de fraudes parce que le numero de carte est transmis sans authentification 
du client. Le fait de disposer d'un numero de carte bancaire (information semi-confidentielle) suffit pour passer des 
ordres au nom d'une personne. Un gen^rateur de numSro coh6rents de cartes bancaires peut etre utilise a cet effet. 

30 Les solutions de paiement securisS par carte bancaire sur Internet s'appuyant sur la troisieme approche, 

mettent en ceuvre aujourd'hui des interm&iiaires de paiement s6curis6 par carte (notes IPSC). Un IPSC assure 
Tinterface entre Tlnternet et un reseau de cartes bancaire. 



La communication entre le client et 1'intermediaire bancaire utilise un des principes suivants 



le numSro de carte est transmis par le client a chaque ^change (figure 1 ) 

le numero de carte est stock6 sur le terminal client et c'est un logiciel qui se charge de realiser la 

transaction avec le serveur intermediate bancaire du vendeur 

le client est enregistre aupres de 1'IPSC, qui conserve son numero de carte et qui interroge le reseau 
40 cartes bancaires a chaque transaction. 

Pour ce qui est du paiement par les mobiles les solutions proposees restent limitees a la gestion du systeme 
d'information de I'operateur de mobile. 

45 Definitions 

On entend par faiblement non repudiable, un dispositif transactional qui en utilisation normale utilise des 
informations connues du seul client pour signer la transaction et ne pouvant etre transmises vers un hote exterieur 
que si le client realise une operation non autorisee, pouvant creer un trou de securite comme la mise en place d'un 
espion dans son systeme de signature electronique. 



Un systeme faiblement non repudiable, si le client s'engage a ne pas op6rer certaines operations et en 
accepte les regies contractuellement, devient non repudiable par le client. 
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Objectif du dispositif 

L'objectif principal du dispositif est d'apporter une amelioration aux solutions de type transmission du 
numgro de carte systdmatique, permettant de limiter les risques de fraude a une fraction nSgligeable des transactions 
en introduisant la quality de "non repudiation faible". Le deuxieme objectif est de permettre des transactions unifiees 
5 Web/t6l6phone mobile. 



Description du dispositif 

Le dispositif propose utilise un serveur Internet (8/2) agissant comme mandataire de paiement oriente client 
et intervenant en intermediate dans les echanges entre des systemes 1PSC (6/2) et le terminal client (7/2). Le 
10 serveur mandataire peut egalement effectuer des demandes d'autorisation vers des systemes de paiement autres. Ce 
dispositif utilise un mecanisme de signature faiblement non repudiable pour authentifier les requetes de paiement en 
provenance des clients. Son originalite est qu'il s'appuie sur des acces multi-terminaux. On distinguera 4 types de 
terminaux : 

15 le PC fixe (etant suppose a domicile) 

le PC occasionnel, dit PC anonyme (ex : borne multimedia publique) 
le telephone mobile simple 

le t616phone mobile de type WAP, avec ou sans module WIM. 

20 Lorsque la prise de commande est faite sur un terminal anonyme, le serveur mandataire de paiement 

requiert une validation par un terminal telephone mobile. 

Dans 1'utilisation de base, c'est-a-dire depuis un PC fixe personnel, le client installe un certificat standard delivre' par 
le mandataire de paiement a Inscription comprenant entre autres une cle privee a importer dans le navigateur du 
25 PC. Lors de Timportation, le client choisit : 

un code personnel appele* code de security (CODECS) qui protege Pusage de son certificat 
un code de validation (CODE_V) qui sera utilise pour valider les transactions. 

Le bouton achat d'un transaction en ligne comprend en parametres signes par le site vendeur : le contenu de la 
30 transaction, le prix, le code vendeur et consiste en un lien vers une demande de paiement vers le serveur mandataire. 
L'action sur ce bouton declenche une liaison SSL entre le poste client et le mandataire de paiement et le passage des 
parametres precedents. Le passage en mode SSL provoque l'acces au certificat client et done une demande d'entree 
du code de security pour son deverrouillage local. Si le code est correct la liaison est etablie et le serveur mandataire 
authentifle le client. 

35 

Le code vendeur passd en parametre sert a etablir le relais vers le bon IPSC (celui du vendeur) et a verifier que cet 
1PSC accepte bien le mode de paiement du client. L'agent de securite dispose de plusieurs interfaces pour simuler les 
echanges d'un client avec les divers IPSC. 

40 Lorsque le client intervient sur une bome anonyme ou chez un commercant qui saisit en ligne la prise de commande 
pour son compte, celle-ci a ete initialisee pour ne pas acceder au certificat Dans ce cas les parametres sont passes 
simplement en clair vers le serveur mandataire qui bloque le relayage en attente de validation par telephone mobile 
et en affichant sur le poste client un numero de transaction fixe* par lui. 

45 Pour chaque achat a valider, ce numero unique identifie la transaction (vendeur, commande, client) et doit etre signe 
par le serveur mandataire. 

Trois cas de validation sont traites : 

1 . Cas du telephone simple (figure 3) 
50 2. Cas du tdlephone WAP simple (figure 4) 

3. Cas du telephone WAP avec module WIM : authentification forte du client (figure 5) 

Note : 

Le telephone mobile peut etre a la fois consideVe* comme un terminal de prise de commande et de 
55 d£clenchement de paiement. La prise de commande se fait comme sur un terminal de type PC. 
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Inscription /Installation 

L'inscription du client aupr£s du serveur mandataire (figure 2-b) est realisee de maniere strictement 
confidentielte : on peut utiliser un enregistrement en ligne avec SSL par exemple ou un enregistrement au guichet 

Une procedure de validation par les exploitants du serveur mandataire, peut-etre demandee. Elle doit 
assurer que les informations relevdes k Proscription sont valides. 

Si le client a demande un enregistrement pour PC fixe, le serveur mandataire produit un certificat 
electronique a base de cles publiques de type X509 6mis avec sa cle privee au client par messagerie (10/2). Le 
certificat est encapsule dans un format qui declenche l'auto-installation sur le PC client. A Installation du certificat, 
le client est invite a definir son code de protection des cles CODE_S, connu de lui seul et utilise localement 

Si le client a demand^ la validation par mobile, il fournit son numdro de mobile et choisit un autre code de 
securite, appeld code de validation CODE_V connu de lui seul et du serveur mandataire. 

Les donnSes foumies par le client et conservees sur le serveur mandataire sont : 

l'identiti (nom, prdnom) 

son numero de carte 

l'adresse de livraison habituelle 

optionnellement : numero de GSM 
- le CODE_V. 



Validation de I'identite client 

Suivant la rigueur de la procedure souhaitte, il peut y avoir validation manuelle ou automatique, ou 
simplement aucune validation (acceptation de toutes les inscriptions) sauf des controles de non ^-inscription. En 
particulier des controles de reutilisation sur les messages electroniques et numero de carte permettent de reduire les 
effets de re-inscription. 

Transactions 

Depuis son PC initialise 

Les achats sont r6alis£s par un simple hyperlien vers le serveur mandataire par le protocole HTTP, les 
donnees de la transaction etant passees en parametres. Ces donnees sont signees par le vendeur pour garantir 
Fintegrite vis-a-vis du vendeur. 

La requete de paiement re9ue au serveur mandataire permet d'authentifier le client de mantere certaine, car 
la requete en mode SSL provient d'un PC fixe avec certificat. Dans ce cas, la requete est automatiquement validde et 
imm^diatement relayee. 

Depuis un PC anonyme 

Si la requete est 6mise depuis un PC anonyme, le relayage est bloqu6 sur le serveur mandataire en attente 
de validation par le canal mobile (l'agent n'a pas authentifid de client). Le serveur mandataire demande I'identite du 
client et emet un numero de transaction unique signe par lui pour la validation qui s'opere selon un des 3 modes 
autorises. 



Validation 

1. Validation par telephone 

Le client appelle un numero fixe, qui le met en communication avec un serveur vocal interactif ; il est invite 
a entrer le numSro unique de transaction, affiche sur Tecran de prise de commande; le serveur restitue par synthese 
vocale le descriptif de la commande ; si celui-ci est correct, le client entre son code de validation CODE_V. 

La passerelle envoie une requete de paiement chiffree et signee par elle contenant : l'identificateur de 
transaction et le CODE_V introduit. 

2. Validation WAP simple : 

Dans ce cas le client etablit une connexion WAP/ SSL vers le service validation du serveur mandataire de 
paiement ; le client s'identifie par son nom et prenom puis entre son code de validation CODE_V 
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3. Validation WAP avec module WIM ("WAP Identity Module") 

Ce cas est identique sur le principe au cas 2, sauf que le terminal WAP dispose d*une capacite de signature 
electronique garantissant Tauthentification du client ; dans ce cas, le CODE_V est sign£ par le module WIM avec les 
param&tres de la transaction. 



Note: 

Dans les cas 2 et 3 (validation WAP), la passerelle peut utiliser une methode de memorisation de Tidentite client par 
Cookie. Le Cookie est un enregistrement en clair ASCII comprenant le nom, prenom du client signe* par le serveur 
mandataire. 



Exemple complementation 

Ce dispositif a 6te implements sur un serveur sous systeme Linux avec un pare-feu frontal sous Linux, et un 
IPSC operational. Le systeme utilise HTTPS pour les echange SSL entre le PC client et Tagent de securite. 

La validation par mobile a ete" r£alis£e par un terminal WAP, selon le mode d'acc&s simple. 
L'authentification depuis le telephone mobile s'opere par nom prenom, puis introduction du code de securite passe 
en session SSL. 
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Revendications 

1 . Oispositif de mandatement pour les paiements securises en ligne sur Internet sur des boutiques qui 
utilisent le chififrement SSL pour la transmission du numero de carte sans authentification du client 
vers un serveur d'autorisation bancaire, caracterise en ce qu'il 

- comprend un moyen d'inscription des clients permettant de transmettre au mandataire le numero de 
carte une seule fois a l'inscription, et ceci de maniere securisee par liaison SSL 

- s' interpose au cours d'une transaction d'achat dans les echanges entre le terminal client et le serveur 
^interrogation du reseau cartes bancaires de la boutique, d'une part en identifiant et authentifiant le 
client grace a un mecanisme propre de signature electronique, et d'autre part en transmettant le numero 
de carte client, memorise a l'inscription client, vers l'intermediaire bancaire par la liaison SSL 
habituelle, sans authentification du mandataire de la part de l'intermediaire bancaire. 

2. Dispositif de mandatement de paiement selon les revendications 1 , caracterise par le fait qu'il utilise 
pour chaque client un certificat X509 standard genere sur le serveur mandataire a Inscription client et 
transmis par messagerie avec la cle privee associee pour etre importe dans le navigateur client, puis 
utilise cnsuite pour authentifier les clients dans les liaisons HTTP dans les transactions de paiement. 

3. Dispositif de mandatement de paiement selon les revendications I, caracterise par le couplage possible 
a un dispositif auxiliaire permettant la validation par le telephone mobile simple ou WAP, exploitant 
1'authentification du client par ce systeme auxiliaire et l'usage d'un code de validation connu seulement 
du client et du serveur mandataire. 



3/15/05, EAST Version: 2.0.1.4 



WO 02/29742 



PCT/FR01/03072 



1/5 



Figure 1 : Etat de Fart 
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Figure 2-a : Transaction depuis PC initialise 
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Figure 2-b: Inscription client sur PC initialise 
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Figure 3 : Validation directe par GSM 
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Figure 4 : Validation WAP simple 
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Figure 5 : Validation WAP avec module WIM 
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